docs: downstream effect events corrected #187
Conversation
| For easier visualization, here are all of the events we plan to implement, described from end to end: | ||
| For easier visualization, here are all of the downstream effects we plan to port, described from end to end: | ||
|
|
||
| Downstream effects to be implemented as part of this decision: |
There was a problem hiding this comment.
NIT: after seeing this table rendered. The general context / expected result columns are way more useful than the exact files/functions we are calling but get cutoff when viewing the page. I'd move those left so people can read them easily. TBH the file/function might not even be worth it if it doesn't really fit on the page.
| As such, we plan to use the event bus to send info to edx-platform services without needing a response as one would in a REST framework. | ||
|
|
||
| Below are lists of downstream effects of exam submission and review that we will or will not be translating into events in edx-exams as part of this decision. | ||
| Below are lists of downstream effects of exam submission and review that we will or will not be impementing as downstream effects that will be |
There was a problem hiding this comment.
| Below are lists of downstream effects of exam submission and review that we will or will not be impementing as downstream effects that will be | |
| Below are lists of downstream effects of exam submission and review that we will or will not be implementing as downstream effects that will be |
There was a problem hiding this comment.
I'm having a hard time understanding this sentence. I've read it three times and am still struggling. Maybe it's because it's Friday afternoon.
Are you trying to say something like this?
"Below are lists of expected downstream effects of exam submission and review. We have decided to implement some downstream effects and not others; these decisions are enumerated below. Those that will be implemented will be triggered by events emitted by the edx-exams service, as described in this decision."
| Exam Attempt Submitted When an exam attempt is submitted. Instructor Mark Subsection Completed, Set Credit Requirement Status | ||
| Exam Attempt Rejected When an exam attempt is rejected. Set Credit Requirement Status, Grades Override, Invalidate Certificate | ||
| Exam Attempt Verified When an exam attempt is verified. Set Credit Requirement Status, Undo Grades Override | ||
| Exam Attempt Errored When exam attempt errors out. Set Credit Requirement Status |
There was a problem hiding this comment.
| Exam Attempt Errored When exam attempt errors out. Set Credit Requirement Status | |
| Exam Attempt Errored When an exam attempt errors out. Set Credit Requirement Status |
|
|
||
| Downstream effects to be implemented as events: | ||
| Downstream effects to be implemented: |
There was a problem hiding this comment.
I'm noticing a slight mismatch between the names in this section and the names in the Downstream effects to be implemented as part of this decision section.
| ====================================== ================================================================================================ ============================================ =============================================== ========================================================================= ====================================================================================== | ||
| Grades Override When an exam attempt is rejected. lms/djangoapps/grades/signals.py override_subsection_grade in api.py When we need to override a grade from any service. A grade override object is created or modified in the grades service within the LMS. | ||
| Undo Grades Override When an exam attempt is verified after previously being rejected, OR when it is deleted/reset. lms/djangoapps/grades/signals.py undo_override_subsection_grade in services.py When we need to undo a grade override from any service. A grade override object is deleted in the grades service within the LMS. | ||
| Instructor Reset Subsection When an exam attempt is deleted/reset. lms/djangoapps/instructor/signals.py reset_student_attempts in enrollments.py When we need to reset a student’s state in a subsection. A learner's state for a subsection is reset. |
There was a problem hiding this comment.
This is nit, but every time I see this, I read it as relating to the instructor dashboard reset feature, not the instructor service. This makes me read "Instructor Mark Subsection Completed the same way, even though it has nothing to do with the instructor dashboard. Do you think we need to keep "instructor" in these names, since the other downstream effects don't contain the related service names? I think it makes it confusing.
Corrected this ADR to align with the hackathon doc: https://2u-internal.atlassian.net/wiki/spaces/PT/pages/577699957/M6+Hackathon+Outline#Event-Signals%2C-Their-Data%2C-and-Destinations%3A